CVE-2026-43503
net: skbuff: propagate shared-frag marker through frag-transfer helpers
Description
In the Linux kernel, the following vulnerability has been resolved: net: skbuff: propagate shared-frag marker through frag-transfer helpers Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when moving frags from source to destination. __pskb_copy_fclone() defers the rest of the shinfo metadata to skb_copy_header() after copying frag descriptors, but that helper only carries over gso_{size,segs, type} and never touches skb_shinfo()->flags; skb_shift() moves frag descriptors directly and leaves flags untouched. As a result, the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while reporting skb_has_shared_frag() as false. The mismatch is harmful in any in-place writer that uses skb_has_shared_frag() to decide whether shared pages must be detoured through skb_cow_data(). ESP input is one such writer (esp4.c, esp6.c), and a single nft 'dup to <local>' rule -- or any other nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d skb in esp_input() with the marker stripped, letting an unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray writes. Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors were actually moved from the source. skb_copy() and skb_copy_expand() share skb_copy_header() too but linearize all paged data into freshly allocated head storage and emerge with nr_frags == 0, so skb_has_shared_frag() returns false on its own; they need no change. The same omission exists in skb_gro_receive() and skb_gro_receive_list(). The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a direct frag-move loop and the head_frag + memcpy path); the latter chains the incoming skb whole onto p's frag_list. Downstream skb_segment() reads only skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's shinfo as the nskb -- both p and lp must carry the marker. The same omission also exists in tcp_clone_payload(), which builds an MTU probe skb by moving frag descriptors from skbs on sk_write_queue into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but a future consumer depending on the marker would regress silently. The same omission exists in skb_segment(): the per-iteration flag merge takes only head_skb's flag, and the inner switch that rebinds frag_skb to list_skb on head_skb-frags exhaustion does not fold the new frag_skb's flag into nskb. Fold frag_skb's flag at both sites so segments drawing frags from frag_list members carry the marker.
INFO
Published Date :
May 23, 2026, 12:17 p.m.
Last Modified :
July 2, 2026, 12:17 p.m.
Remotely Exploit :
No
Source :
416baaa9-dc9f-4396-8d5f-8c081fb06d67
CVSS Scores
| Score | Version | Severity | Vector | Exploitability Score | Impact Score | Source |
|---|---|---|---|---|---|---|
| CVSS 3.1 | HIGH | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | ||||
| CVSS 3.1 | HIGH | 0b0ca135-0b70-47e7-9f44-1890c2a1c46c |
Solution
- Update the Linux kernel to include the fix.
- Ensure skb_try_coalesce preserves the shared frag marker.
- Verify ESP input checks handle shared frags correctly.
Public PoC/Exploit Available at Github
CVE-2026-43503 has a 21 public
PoC/Exploit available at Github.
Go to the Public Exploits tab to see the list.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2026-43503.
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2026-43503 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2026-43503
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
None
Python
None
C
DirtyClone - local privilege escalation (LPE) proof-of-concept targeting a kernel/XFRM-related vulnerability described in the source as CVE-2026-43503
Python
Python Proof of Concept for DirtyClone (CVE-2026-43503) - Linux kernel LPE via page-cache corruption
Python
DirtyClone - local privilege escalation (LPE) proof-of-concept targeting a kernel/XFRM-related vulnerability described in the source as CVE-2026-43503
C
Educational, defensive kit for two Linux page-cache-corruption LPEs (DirtyClone CVE-2026-43503, pedit COW CVE-2026-46331): hardening, detection, verification, seccomp + validation harness. Detection and prevention only — no exploit code. TLP:CLEAR.
blue-team bpftrace container-security cve defensive-security ebpf hardening kernel-security linux page-cache privilege-escalation seccomp
Shell
None
None
Python
None
Python
CVE-2026-43503
C
Go-based Scanner for several 2025-2026 Linux root kernel vulnerabilities (DirtyFrag, Fragnesia, Copy Fail, Fragnesia, DirtyPipe, DirtyClone, pedit COW))
appsec detection-engineering kernel-vulnerability linux security vulnerability-scanner
Makefile Go
RootHawkX 是一个 Linux 本地安全测试终端工具,本项目基于RootHawk进行修改，集成了更多漏洞利用模块。
Go C Batchfile Shell
A collection of CVE reproductions with proof-of-concept code, technical analyses, and detailed write-ups. For defensive research and educational purposes.
Python Java Ruby Shell Dockerfile PHP C
Патч-скрипты для устранения критических уязвимостей (Copy Fail, Dirty Frag, PinTheft, GRO Frag) в РЕД ОС 7.3 и РЕД ОС 8.0
fstec linux-kernel security-scripts red-os cve-mitigation
Shell
Linux提权
Go C
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2026-43503 vulnerability anywhere in the article.
-
security.nl
Tails-gebruikers te ontmaskeren via Linux-lekken DirtyClone en pedit COW
De makers van het op privacy gerichte besturingssysteem hebben een nieuwe versie uitgebracht die twee kwetsbaarheden in de Linux-kernel verhelpt waardoor gebruikers zijn te ontmaskeren. Het gaat om de ... Read more
-
The Hacker News
New DirtyClone Linux Kernel Flaw Lets Local Users Gain Root via Cloned Packets
DirtyClone is a new Linux kernel privilege escalation in the DirtyFrag family. JFrog Security Research published a working exploit walkthrough for the flaw on June 25, the first public demonstration f ... Read more
-
security.nl
Privacy-OS Tails komt wegens ernstig Linux-lek met noodpatch
Het op privacy gerichte besturingssysteem Tails heeft wegens een ernstige kwetsbaarheid in de Linux-kernel een noodpatch uitgebracht. Via het beveiligingslek zou een met Tails meegeleverde applicatie ... Read more
The following table lists the changes that have been made to the
CVE-2026-43503 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
May. 30, 2026
Action Type Old Value New Value Added CVSS V3.1 AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H -
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
May. 25, 2026
Action Type Old Value New Value Added Reference https://git.kernel.org/stable/c/48f6a5356a33dd78e7144ae1faef95ffc990aae0 -
CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
May. 23, 2026
Action Type Old Value New Value Changed Description In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors. In the Linux kernel, the following vulnerability has been resolved: net: skbuff: propagate shared-frag marker through frag-transfer helpers Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when moving frags from source to destination. __pskb_copy_fclone() defers the rest of the shinfo metadata to skb_copy_header() after copying frag descriptors, but that helper only carries over gso_{size,segs, type} and never touches skb_shinfo()->flags; skb_shift() moves frag descriptors directly and leaves flags untouched. As a result, the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while reporting skb_has_shared_frag() as false. The mismatch is harmful in any in-place writer that uses skb_has_shared_frag() to decide whether shared pages must be detoured through skb_cow_data(). ESP input is one such writer (esp4.c, esp6.c), and a single nft 'dup to <local>' rule -- or any other nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d skb in esp_input() with the marker stripped, letting an unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray writes. Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors were actually moved from the source. skb_copy() and skb_copy_expand() share skb_copy_header() too but linearize all paged data into freshly allocated head storage and emerge with nr_frags == 0, so skb_has_shared_frag() returns false on its own; they need no change. The same omission exists in skb_gro_receive() and skb_gro_receive_list(). The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a direct frag-move loop and the head_frag + memcpy path); the latter chains the incoming skb whole onto p's frag_list. Downstream skb_segment() reads only skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's shinfo as the nskb -- both p and lp must carry the marker. The same omission also exists in tcp_clone_payload(), which builds an MTU probe skb by moving frag descriptors from skbs on sk_write_queue into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but a future consumer depending on the marker would regress silently. The same omission exists in skb_segment(): the per-iteration flag merge takes only head_skb's flag, and the inner switch that rebinds frag_skb to list_skb on head_skb-frags exhaustion does not fold the new frag_skb's flag into nskb. Fold frag_skb's flag at both sites so segments drawing frags from frag_list members carry the marker. Added Reference https://git.kernel.org/stable/c/12401fcfb01f53ccc63ab0a3246570fe8f3105ee Added Reference https://git.kernel.org/stable/c/179f1852bdedc300e373e807cc102cd81feff196 Added Reference https://git.kernel.org/stable/c/989214c66884d70716d83dc1d0bf5e16287bf349 Added Reference https://git.kernel.org/stable/c/9bc9d6d6967a2239aa57af2aa53554eddd640d20 Added Reference https://git.kernel.org/stable/c/fbeab9555564a1b98e8582cd106dfe46c4606991 Added Reference https://git.kernel.org/stable/c/fc6eb39c55e97df2f94ad974b8a5bbcd019da2c8 Added Reference https://git.kernel.org/stable/c/ff375cc75f9167168db38e0464a482d5fbc8d81d Removed Reference https://git.kernel.org/stable/c/2f2b16022a2e10ca7bccfb98db5ed2ec0f72641c Removed Reference https://git.kernel.org/stable/c/3599e6b3cc1ada96883d496a50a210d3afbb6987 Removed Reference https://git.kernel.org/stable/c/3884358a9286b17f389a72b1426fc4547c23c111 Removed Reference https://git.kernel.org/stable/c/3bd9e113d50034db99d7ef69fd8e5242d15e414a Removed Reference https://git.kernel.org/stable/c/760e1addc27ba1a7beb4a0a7e8b3e9ec49e7a34e Removed Reference https://git.kernel.org/stable/c/78bf6b6bb19541d19fbda6242e7cfe2c682763c0 Removed Reference https://git.kernel.org/stable/c/9d3e5fd19fe1063bf607219e8562fbd567b8e8d5 -
New CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
May. 23, 2026
Action Type Old Value New Value Added Description In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors. Added Reference https://git.kernel.org/stable/c/2f2b16022a2e10ca7bccfb98db5ed2ec0f72641c Added Reference https://git.kernel.org/stable/c/3599e6b3cc1ada96883d496a50a210d3afbb6987 Added Reference https://git.kernel.org/stable/c/3884358a9286b17f389a72b1426fc4547c23c111 Added Reference https://git.kernel.org/stable/c/3bd9e113d50034db99d7ef69fd8e5242d15e414a Added Reference https://git.kernel.org/stable/c/760e1addc27ba1a7beb4a0a7e8b3e9ec49e7a34e Added Reference https://git.kernel.org/stable/c/78bf6b6bb19541d19fbda6242e7cfe2c682763c0 Added Reference https://git.kernel.org/stable/c/9d3e5fd19fe1063bf607219e8562fbd567b8e8d5